Do we need to add it to React repo at all? It seems to me like this can live in the RN repo (it will be synced there anyway). I don't have a strong opinion though.

We don't need to, but it really belongs there I think, given how the shims work and how this file is coupled to the deferred runtime flag in the fork.

To clarify, AFAIK the only reason we added "shims" to the build process at all is to remove all __INTERNAL access in RN repo. This allows us to know when it's safe to remove an internal property.

True!

We use shims for other things in RN too though, like ReactNative.

We use shims for other things in RN too though, like ReactNative.

AFAIK the initial plan was to delete them asap. We just never did it. We tried to keep the Rollup PR simple and require little to not changes in RN repo for next sync. So we had a file for every Haste require that would go missing.

Isn't this similar to ReactFeatureFlags-www.js?

No. ReactFeatureFlags-www.js is more similar to ReactNativeFeatureFlags. Note how it requires the dynamic version inside of it. :-) The dynamic version exists in www. Because it depends on GK.

Yeah, I just noticed that, although it's also in the "shims" sub-dir... Hm.

I still think b'c of the RN sync workflow (React GitHub -> fbsource -> ReactNative GitHub) it makes slightly more sense to put the file here.

Let's agree to disagree 😛 I don't think there's a single good answer here.

I do think that we'll never want to change this file without changing its cousin in fbsource though. So my natural instinct is to put its source of truth closer to fbsource (RN GH) than away from it (here). Especially since we don't actually depend on this file for our purposes in this repo. I would also prefer to keep www and RN workflows more symmetric.

I thought similarly- that we wouldn't want to change ReactNativeFeatureFlags without changing the shim. Which is why I thought it made sense to keep in GitHub rather than fbsource.

I agree that there's not an obvious best answer here.

Agree to disagree then. 😄 We can always revisit later if one approach becomes more obviously correct.

Again, I don't feel strongly about it though. Takes a few iterations to find a good balance. Maybe let's try it this way.

Cool. Thanks for the discussion. 😄